home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / dcom / modems-part1 / 3998 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.1 KB
  1. Path: sobt.accessorl.net!user
  2. From: eric@accessorl.net (Eric Shaw)
  3. Newsgroups: comp.dcom.modems
  4. Subject: Re: To V42Bis or not to V42Bis??
  5. Date: Sun, 04 Feb 1996 20:03:49 -0500
  6. Organization: Access Orlando
  7. Message-ID: <eric-0402962003490001@sobt.accessorl.net>
  8. References: <4ej6rh$oa2@canopus.cc.umanitoba.ca> <4eruq2$e2@hg.oro.net> <4etjse$a0g@azure.acsu.buffalo.edu> <4f0jnq$dr7@hg.oro.net>
  9. NNTP-Posting-Host: sobt.accessorl.net
  10.  
  11. In article <4f0jnq$dr7@hg.oro.net>, estarry@oro.net (Ed Starry) wrote:
  12.  
  13. >~the extra overhead involved in compressing files can slow down
  14. >~your throughput.
  15. >
  16. >        If you really believe this you had better get your calculator
  17. fixed. When I
  18. >see 7,000 CPS throughput rates I don't care how much 'extra overhead' there
  19. >is, 7,000 is 7,000! I always thought 7,000 CPS was faster than 2,880 CPS?
  20.  
  21. In the case of compressible files that can be sent at 7000 cps, you are
  22. obviously right.  That is not what I was refering to.  If a file is only
  23. slightly compressible, i.e. the best compression engine would give you
  24. 3500 CPS, then a slower compression routine could take extra overhead,
  25. bringing you below the rate you'd get with compression off. For example,
  26. you might get 3388 CPS with compression off, but only 3300 with
  27. compression on if the file is not very compressible, not because v.42bis
  28. is making the file bigger, but because the modem took too long to figure
  29. out that it couldn't compress it well.   This doesn't happen often, and
  30. the slowdown is usually so small that the parts of the file that compress
  31. a little quicker counter it, but it is possible for it to be a tiny bit
  32. slower with compression. (with MNP5 it is A LOT slower with "compression",
  33. but thats for other reasons)
  34.  
  35. Note: the 3388cps without compression comes from dividing 28800 by 8.5
  36. bits/byte instead of 10.  Error correction strips out the start and stop
  37. bits between the modems, so there are 8 bits per byte instead of 10 like
  38. you have through the serial port.  I used 8.5 instead of 8 then because
  39. there is a little bit of overhead for the v.42 checksums.  The number is
  40. not *exactly* 8.5, but it is close.  The exact number depends on your v.42
  41. packet size.
  42.